All OGC Web Services (OWS) (WMS, WFS, soon WCS) have several common configuration elements in the Web Admin Tool. Sometime we will allow one to configure these once and choose to inherit from the common configuration or not, but for now you must fill out each service separately. Mostly it is the meta information for the capabilities documents that each serve. If you are just evaluating GeoServer then the meta information need not be configured, but if you are serving GeoServer publically then we highly recommend that you take the time to fill these out appropriately, so that clients don't confuse your layers for the GeoServer defaults. Indeed the only way we will build a true GeoSpatial Web with search and all is if the meta information is filled out correctly. If you are only using one of the WFS and WMS then we recommend that you disable the one not being used in the Contents section. Each Service has a Contents and a Description. The Contents section controls options specific to each, and the Description section focuses on the Capabilities document's meta information.

Description

The Description section represents the Service section of a Capabilities document, common across all OGC Web Services. From the WFS 1.0 spec:

Contents

The Contents section contains an Enabled check box - if you are not using one of the services (or are using another piece of software, such as MapServer, to serve the other service), then we recommend disabling it so that users can not access it. The section also contains the Online Resource section. We admit that this would probably be more appropriate in the GetCapabilities section. According to the specs it is supposed to be the 'home page' of the service. Some web page that you've put up telling about the WMS and/or WFS that GeoServer is providing. If you don't have one set up then we recommend just putting the welcome page to the GeoServer welcome page, as that's what it was designed for.

The WFS Contents section contains four additional options.

srsName as XML determines if the GetFeature results will have the srsName element as an XML attribute, such as:

<MultiLineString srsName="http://www.opengis.net/gml/srs/epsg.xml#27354">

as all examples in the WFS specification are, or as the more terse:

<gml:MultiLineString srsName="EPSG:27354">

We recommend the former (srsName as XML set to true), the main reason we offer the latter is that some clients for some reason have a hard time parsing the former. So if users are complaining of having trouble with their clients parsing things correctly we you may try unchecking srsNames as XML.

The next option is Strict CITE Test Conformance. If you're not running CITE tests then there's no need to worry about this. CITE is the conformance testing suite of the OGC, and it's very specific about several things, checking this makes sure that GeoServer gets it all exactly right (by doing things like leaving off the extra output formats, since they give cite trouble).

Generate feature bounds is the latest option, which makes use of the gml:boundedBy element that is optional in all features to report the bounds of all geometries in the feature. It is automatically generated by GeoServer on the fly if turned on. We generally don't recommend this option, as it can increase your the amount of GML sent to the client up to 40%, since it adds extra lines for every feature. But it can be quite useful for clients to zoom to an area with multiple geometries, as the client does not need to calculate the bounds, GeoServer does it. For information about the interaction between CITE conformance, feature bounds, and using an element named boundedBy, see Generate Feature Bounds Interactions.

The final option is the Service Level, which allows you to 'turn off' access to transactions. This is often a prudent move, if you are opening your GeoServer up to the world, so that not anyone can just come in and modify your configuration. In the future we hope to offer more complex configurations then just 'Basic' and 'Transactional', such as support for user level authentications and the like, but for now it just turns on and off. By modifying the configuration files directly you can get a bit more control, specifying which of insert, update and delete you want to make available. Note that at this time the change is not reflected in the Capabilities document, ie it will still tell the address for Transactions, just none will go through.

Validation

GeoServer 1.3 includes the innovative Validation capabilities, completed by Refractions Research, which gratefully acknowledges the GeoConnections Secretariat for providing matching funds for the development via the GeoInnovations program. It provides a mechanism for ensuring that features edited via GeoServer are spatially clean before allowing them to be inserted into the spatial backend databases. If you are working using GeoServer to its full WFS-T transactional capabilities we strongly recommend that you consider defining a few validation tests. These can be easily defined to ensure simple things like no 0 length geometries, and no dangling lines. But it can also express more complex tests, like ensuring that no streets overlap with defined houses, and that the street name is defined in a Gazetteer.

The Validation configuration is accessed in the WFS section. For 1.3 we don't have time to port and improve the validation guide, so for now just refer to the document created by Refractions, found

• ValidationUserGuide.pdf

If a volunteer wanted to take on the task of making a real validation guide and tutorial, it would be hugely appreciated, as there are some very powerful features there, that no one makes use of since they aren't documented. Indeed uDig 1.1 is starting to use some of the same code, which should hopefully make it easier to define test suites and share between the two. There is also information at: http://vwfs.refractions.net